System and method for generation and validation of multigame with bonus game using an electronic card

ABSTRACT

According to various embodiments, a method for implementing a multigame is disclosed. The method includes randomly generating a plurality of game outcomes for the multigame. The method further includes grouping the plurality of game outcomes into a plurality of batches according to a game specification and assigning a batch number to each of the plurality of batches. The method also includes encoding each batch number with a security code. The method further includes electronically storing each encoded batch number in a respective game card, where each game card is configured to wirelessly communicate the encoded batch number to a user computing device. The method also includes providing a game application for downloading by the user computing device, where the application is configured to provide a gaming display on the user computing device to allow for playing the multigame based on the encoded batch number.

FIELD OF THE INVENTION

The present invention relates generally to games of chance and, moreparticularly, to a gaming system and method for providing electronictickets that encode tally counts of predetermined game results stored innon-volatile memory, found within the electronic ticket.

BACKGROUND OF THE INVENTION

The gaming and lottery industries have enjoyed a steady increase inpopularity over time. This increase has produced a competitivemarketplace for instant win type games of chance.

FIG. 1 is an example of a prior art instant win pull tab ticket gamesystem. A game specification 7 and a set of game rules (not shown)define the characteristics of the pull tab ticket game. The lotteryoffice 3 coordinates the printing and distribution of the pull tabtickets to the authorized retailers 4. A game player 5 can purchase oneor more pull tab tickets 6 from one or more lottery retailers 4. Thepull tab ticket purchased by the player 5 is manufactured by the GameCard Manufacturer facility 1 and distributed to the authorized lotteryretailers 4 via the main lottery office 3.

Depending on hidden indicia revealed on the pull tab ticket 6, thefollowing options are available to the player 5:

(A) There is no winner amount. There is no further action required bythe player.

(B) The player has won a monetary prize below a specific threshold (thestate lottery commission sets this threshold) and is able to “cash in”the scratch off ticket at a lottery retailer 4.

(C) The player has won a monetary prize above the specific threshold.The player can mail in a claim form with their winning ticket to thelottery office 3 to receive the monetary prize or directly visit thelottery office 3 and “cash in” a winning pull tab ticket 6.

While pull tab tickets 6 typically allow a player 5 the opportunity towin multiple times on a ticket, this approach can lead to limited gameplay, requires a specialized printing process, adds additional expensesto produce a pull tab ticket, and uses what some would considerantiquated “paper” technology.

U.S. Pat. No. 9,911,274 discloses a secure distributed gambling systemwhich includes a plurality of secure gambling microprocessors. Thesystem disclosed requires the gambling microprocessors to contain aRandom Number Generator and Cryptographic Coprocessor for securitypurposes. Furthermore, the system requires communications between thegambling microprocessors to support bidirectional communications betweenitself and the plurality of mobile devices.

U.S. Pat. No. 10,360,577 discloses a system for coupons to beelectronically distributed to mobile devices. The disclosed systemrequires the mobile device to be within a broadcast range for eachgaming session. The system also requires the coupon generating system tohave a random number generator for the generation of the result of thegaming session.

U.S. Pat. No. 10,366,564 discloses a gaming system that allows users toparticipate in draw games utilizing a portable microprocessor, a mobiledevice, and a game server. The gaming system requires bi-directionalencrypted communication between the portable microprocessor and mobiledevice and between the mobile device and game server for each wagerincreasing the circuit complexity required on the portablemicroprocessor.

U.S. Pat. No. 10,593,153 discloses a system which allows a consumer toplay a plurality of predetermined instant tickets stored onto a memoryof a microprocessor. The system requires the storage of a validationnumber, outcome, and value of each predetermined instant ticket. Thisleads to a requirement of a large amount of memory storage. The systemalso requires bidirectional communication between the microprocessor andthe computing device for each predetermined instant ticket played.

As such, there is a need for a predetermined multigame system that cancontain a higher number of game outcomes on an inexpensive, easy toproduce game ticket where the game play is transposed into electronicmemory for a more interactive experience, especially with instant wintype games. Users could download software applications onto smartdevices, effectively allowing them to be a personal gaming device. Withthe abundance of “smart” communication devices, such as the Apple orAndroid smart devices, it can be possible to communicate with anelectronic card via communications protocols such as Bluetooth,Near-Field-Communication (NFC), ZIGBEE, or direct wire or wirelesscommunications generally and the internet to lookup or downloadinformation associated with the instant game on the smart device.

A key element when matching a smart device to an instant win ticket isthe ability to represent the predetermined outcomes of a game withlimited memory storage on the electronic card. Error control andverifiability are also desirable attributes of the information placed onthe printed ticket.

SUMMARY OF THE INVENTION

According to various embodiments, a method for implementing a multigameis disclosed. The method includes randomly generating a plurality ofgame outcomes for the multigame. The method further includes groupingthe plurality of game outcomes into a plurality of batches according toa game specification and assigning a batch number to each of theplurality of batches. The method also includes encoding each batchnumber with a security code. The method further includes electronicallystoring each encoded batch number in a respective game card, where eachgame card is configured to wirelessly communicate the encoded batchnumber to a user computing device. The method also includes providing agame application for downloading by the user computing device, where theapplication is configured to provide a gaming display on the usercomputing device to allow for playing the multigame based on the encodedbatch number.

According to various embodiments, an electronic game card for playing amultigame is disclosed. The electronic game card includes an electronicmemory configured to store an encoded batch number corresponding to oneof a plurality of batches of randomly generated game outcomes for themultigame according to a game specification. The electronic game cardfurther includes a device for wireless communication configured towirelessly communicate the encoded batch number to a user computingdevice having a downloaded game application that provides a gamingdisplay to allow for playing the multigame based on the encoded batchnumber.

Various other features and advantages will be made apparent from thefollowing detailed description and the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In order for the advantages of the invention to be readily understood, amore particular description of the invention briefly described abovewill be rendered by reference to specific embodiments that areillustrated in the appended drawings. Understanding that these drawingsdepict only exemplary embodiments of the invention and are not,therefore, to be considered to be limiting its scope, the invention willbe described and explained with additional specificity and detailthrough the use of the accompanying drawings, in which:

FIG. 1 depicts a diagram of a prior art pull tab game system;

FIG. 2(a) depicts an overview diagram of a predetermined multigameticket using an electronic card system according to an embodiment of thepresent invention;

FIG. 2(b) depicts a multigame electronic card using near fieldcommunication (NFC) technology according to an embodiment of the presentinvention;

FIG. 3 depicts a flowchart of a predetermined multigame ePullTab systemprocess according to an embodiment of the present invention;

FIG. 4(a) depicts a sample of predetermined ePullTab multigame parametervalues according to an embodiment of the present invention;

FIG. 4(b) depicts a sample of predetermined ePullTab multigame parametervalues according to an embodiment of the present invention;

FIG. 4(c) depicts a sample of predetermined ePullTab multigame parametervalues according to an embodiment of the present invention;

FIG. 4(d) depicts a sample of predetermined ePullTab multigame parametervalues according to an embodiment of the present invention;

FIG. 5 depicts an overview flowchart of a prize pool population andshuffle according to an embodiment of the present invention;

FIG. 6 depicts a flowchart of a prize pool determination according to anembodiment of the present invention;

FIG. 7(a) depicts a first part of a flowchart of a prize pool populationaccording to an embodiment of the present invention;

FIG. 7(b) depicts a second part of a flowchart of a prize poolpopulation according to an embodiment of the present invention;

FIG. 8(a) depicts a first part of a flowchart of generating game batchesaccording to an embodiment of the present invention;

FIG. 8(b) depicts a second part of a flowchart of generating gamebatches according to an embodiment of the present invention;

FIG. 9 depicts a flowchart of a Durstenfeld shuffle function accordingto an embodiment of the present invention;

FIG. 10 depicts a flowchart of a true random number generator withmodulus according to an embodiment of the present invention;

FIG. 11 depicts a flowchart of a modulus bit mask function according toan embodiment of the present invention;

FIG. 12 depicts a flowchart of a process to initialize the ePullTabcard;

FIG. 13 depicts a flowchart of a security identification code generationsystem according to an embodiment of the present invention;

FIG. 14 depicts a flowchart of a security identification code validationsystem according to an embodiment of the present invention;

FIG. 15 depicts a flowchart of a game outcome encoding functionaccording to an embodiment of the present invention;

FIG. 16 is a flowchart of the smart device application;

FIG. 17 depicts an example of a screenshot of an ePullTab game payouttable on a smart device according to an embodiment of the presentinvention;

FIG. 18 depicts an example of a screenshot of an ePullTab game inprogress on a smart device according to an embodiment of the presentinvention;

FIG. 19 depicts an example of a screenshot of an ePullTab game bonusspin in progress on a smart device according to an embodiment of thepresent invention;

FIG. 20 depicts an example of a screenshot of a completed ePullTab gamebonus spin on a smart device according to an embodiment of the presentinvention;

FIG. 21(a) depicts a first part of an example of game rules according toan embodiment of the present invention;

FIG. 21(b) depicts a second part of an example of game rules accordingto an embodiment of the present invention

FIG. 22 depicts an example of a server farm according to an embodimentof the present invention;

FIG. 23 depicts an example of a specification computer system accordingto an embodiment of the present invention; and

FIG. 24 depicts an example of an eCard Initialization computer subsystemaccording to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Generally disclosed herein are embodiments for a gaming system andmethod for generating and playing predetermined multigame electroniccards (i.e. an electronic card containing multiple games or multiplerounds of a single type of game). The player “pairs” the electronic cardto their smart device and plays the encoded multigames using an internetdownloaded software application program.

Embodiments of the present invention preserve the advantages of theprior art approaches for the production and playing of multigame ticketswhile providing for a denser storage capability of predeterminedoutcomes using electronic communication techniques, as well as providingfor a security system and method for ticket verification.

The denser storage capability is provided by generating and batchingpredetermined game outcomes, determining the number of each type ofoutcome in a batch and storing the tally count on an electronic cardcontaining electronic memory.

The predetermined outcomes are generated using outcome results fromspecification tables and a random number generator. The predeterminedoutcomes are shuffled and batched into subgroups. The size of a subgroupis defined in the predefined game rules. A security code is generatedfor each batch of predetermined outcomes. The batch sequence number isencoded into the security code and stored in a secure database for theeventual ticket verification process.

Each subgroup of predetermined outcomes is analyzed to determine thetotal number of each outcome type as defined in the game specifications.The number of each outcome is stored on the electronic card as a tallycount, which will be used by the software application program duringgame play.

Embodiments of the present invention create a game specificationspecifying a game series code number, a total number of tickets, a totalnumber of prize pools (i.e., groups of outcomes), a total number ofprize tiers, a number of prizes for each prize tier based on odds, anamount awarded for each prize level, play symbols, a winning combinationfor each prize level, a number of electronic cards at specifieddenominations, and a cost per game outcome. The game specification canbe created at a lottery office or offsite via a secure network. Gamerules are developed based on the game specification. A smart device(user device) application is also developed based on the gamespecification and game rules.

Embodiments of the present invention determine game outcomes bydetermining which prize pools will contain the prizes with less than 1per pool. An array is created with a number of elements which are thenumber of prize pools. The array is then shuffled. A specified number ofelements are selected based on prizes available to represent which prizepool will contain an associated prize outcome. The prize pools arepopulated with the number of prize pools. The array is again shuffled. Aspecified number of elements are again selected based on prizesavailable to represent which prize pool will contain associated prizeoutcomes. Prize pools are then populated, where each prize pool is anarray with a specified number of elements and initialized to zero. It isthen determined if the prize pool should contain a top tier prize wherethe zeros are overwritten with prize tokens for each prize tier. Eachprize pool is shuffled (for instance with a Durstenfeld Shuffle) forrandomization using a hardware random number generator that incorporatesa bit mask modulus function to eliminate truncation bias. The prize poolarray is stored in a master database to be used later when initializingthe electronic game cards.

Embodiments of the present invention create game batches and initializea plurality of electronic game cards. The prize pool array is loadedfrom a master database. An array is created with a number of elementsbased on the number of prize tiers. Another array is created with anumber of elements to match the number of outcomes associated with anelectronic card. Each type of game outcome is tallied and stored in thefirst array. The game card is then initialized by generating a batch IDassociated with the current array of outcomes. The batch ID is encodedusing for instance a symmetrical encryption/decryption algorithm. Theencoded batch ID is then loaded on the electronic card. Further loadedon the electronic card are the game series code, the outcome count, andthe prize tallies are also loaded on the game card. The prize talliesare encoded prior to loading to mask the count. The total winning amountassociated with game outcomes on an electronic card and a loaderror-detecting code are calculated and loaded on the electronic card aswell. The electronic card is then set to initialized. All batchinformation is stored in a master database for later retrieval forvalidation.

Embodiments of the present invention develop a smart device applicationbased on the specification and rules. The application is previouslydownloaded and installed by a user prior to electronic cardcommunication. The application could be configured based on a singlegame (different application for each game), a game type (sameapplication but different graphics), or a single application for allgames (different graphics and user interactions based on game type). Theuser device via the application would wireless communicate with theelectronic card via near field communication, for instance. Thecommunication can be uni-directional (simplex) or bi-directional(duplex). This wireless communication only needs to occur once. Wirelesscommunication with the lottery office can also occur via internetthrough WiFi (local) network or a mobile data network. All gameparameters associated with a game series ID would be downloadedincluding but not limited to game symbols, win amounts for each prizetier or token number, and winning combinations for each prize tier.Electronic card information would also be downloaded such as a randomnumber associated with a lookup table to decode prize tallies. Oncedownloads are completed game play can be offline. The applicationcreates, populates, and shuffles an outcome array where the length ofthe array equals the number of outcomes associated with an electroniccard. The prize tally is also encoded. A Durstenfeld Shuffle can be usedfor the shuffle. The application calculates and displays the play cardbased on game parameters downloaded and game outcomes. The user theninteracts with the play card to display game outcomes. The outcomes canbe played multiple times on multiple devices with no change to thepayout.

Embodiments of the present invention cash out an electronic card wherewinnings are based on the electronic card rather than per game on thecard. The electronic card is returned to the lottery retailer for cashout payment. If under a specified amount in the rules, the amount may bepaid by a lottery retailer; otherwise, the amount must be paid by thelottery office. Outcomes doe not need to be played for the electroniccard to be cashed out and the card can be recycled for reuse in a latergame.

Important technical advantages of certain embodiments of the presentinvention include generating batched game predetermined outcomes,generating security codes, generating tally counts, and encoding thetally counts and security codes. Compared to U.S. Pat. No. 9,911,274,embodiments of the disclosed system utilize simplified encodingtechniques and simplex communication thus eliminating the need for thecomplex circuitry on the gambling microprocessor. Compared to U.S. Pat.No. 10,360,577, embodiments of the disclosed system advantageously usepredetermined outcomes which reduce the requirements of circuitry foundon the multigame eCard. Further, the embodiments only require simplexcommunication with the mobile devices once, which provides for anenhanced gaming experience. Compared to U.S. Pat. No. 10,366,564,embodiments of the disclosed system utilize predetermined outcomes and asimplified communication technique to reduce the circuit complexityalong with operational costs. Compared to U.S. Pat. No. 10,593,153,embodiments of the disclosed system utilize a technique of storing a“tally count” or summary of each type of predetermined outcome toachieve much high data compression leading to a largely reducedrequirement of memory storage. Further cost reduction is achieved byutilizing a communication technique which uses a one-time only, simplexcommunication scheme.

Additional technical advantages of embodiments of the present inventionwill be readily apparent to one skilled in the art from the followingfigures, description, and claims. Moreover, while specific advantageshave been enumerated above, various embodiments may include all, some,or none of the enumerated advantages. A PullTab type game is used as anonlimiting example of how the method and system perform. However, anypredetermined multigame can be used in conjunction with this system andmethod, such as Black Jack, Craps, and slot machines, as nonlimitingexamples.

FIG. 2(a) is a pictorial overview of a multigame system using multigameelectronic cards (“eCards”). While FIG. 2(a) and subsequent figures mayrefer to the multigame system as “lottery” based, the reference to“lottery” is intended to be a nonlimiting example of a multigame systemor method. A game specification 59 and the game rules (not shown) definethe characteristics of the multigame eCard. The game specification 59may be developed at a secure site external to the main multigame lotteryoffice 52. Communication of the game specification may occur using asecure data network 58. The main lottery office 52 uses the gamespecifications 59 and game rules along with a hardware random numbergenerator 61 to create and shuffle the game outcomes. The main lotteryoffice 52 generates batches of the game outcomes as defined in the gamespecification file 59 and stores the batch information in a databaseserver 60. The main lottery office 52 coordinates with the securemultigame electronic card manufacturing facility 50 to initialize themultigame eCards 54 with the batch information as stored in the databaseserver 60. The main lottery office 52 may utilize a courier, a deliveryservice, or other means to physically distribute 51 the printedmultigame eCards 54 to authorized retailers 53 (such as lotteryretailers). Players 56, 57 can purchase the multigame game eCard 54 fromany of the authorized retailers 53. Using a communications link such asBluetooth or NFC, as nonlimiting examples, in their smart device 55, theplayer is able to display all the batch information stored on the eCard54. Using a software application, the smart device 55 is able to displaythe batched predetermined game outcomes and determine the winning amountassociated with the multigame eCard 54.

FIG. 2(b) is a schematic representation of an example of thearchitecture of a multigame electronic card 54 using non-limiting NFCtechnology. The resonant energy accumulator 70 captures a nearby smartdevice's radio frequency signal 75 via a loop antenna 71 to convert thesignal into a power source. The voltage regulator 72 receives theunregulated power source signal and outputs a regulated voltage, VCC 79,for use by other circuit components. When VCC 79 is initially supplied,the reset circuit 73 generates a reset signal 74 to the low power CPU 78which is then initialized and begins execution of the program stored inthe program store ROM 83. The low power CPU 78 uses the working RAM 84for temporary data storage while executing the program stored in the ROM83. The flash data store EEPROM 85 is used to store data such as themultigame data structure. The data structure stored in the flash dataEEPROM 85 includes 34 bytes of data representing the 8 byte Security IDCode, the 4 byte Game Series Code, a 1 byte Total Outcome Count, 13bytes for Prize Tier Tally Counts, a 4 byte Total Win Amount, and a 4byte CRC-32 Data Checksum. This data structure illustrates anon-limiting embodiment which describes a game with 13 prize tiers and amaximum of 255 outcomes supported per multigame eCard 54. With minimalincrease to the Flash data store EEPROM 85 required, the data structurecould be redefined to accommodate a larger or smaller number of prizetiers and by increasing the size of the Total Outcome Count the totaloutcomes per multigame eCard 54 could be increased substantially. TheMaster Clock Generator 80 generates a signal used by the CPU 78 toderive the data communications timing. The I/O Interface 82 includescircuitry that allows the multigame eCard 54 to communicate with thesmart device via an NFC communication protocol. The radio frequencytransceiver (or more simply a transmitter depending on the embodiment)81 may share circuitry for both the transmission and reception ofwireless data between the smart device and multigame eCard 54 via the RFAntenna 76. The transmission and reception of the wireless data can besimplex, half duplex, or full duplex depending on the complexity of theradio frequency transceiver.

FIG. 3 is a flow diagram representing a simplified overview of the lifecycle for the multigame eCard. The flow diagram starts 100 after theeCard has been initialized and distributed to an authorized retailer.The player visits the authorized retailer and in step 101 purchases themultigame eCard at the price documented in the game rules. In step 102the player “pairs” or associates the eCard to their smart device byinitiating communications between the eCard and the smart device. Thepreviously downloaded software application running on the smart devicewill retrieve the tally counts stored on the eCard and create andshuffle an array containing the specified amount of game outcomes (notshown). The application will then select the next game outcome in thearray and create the game board for player interaction in step 103. Ifthe software application requires downloading, the player will beprompted to download the application using a link stored in theelectronic memory. Once the player has concluded interaction with thegame outcome (game is finished), the software application determines ifthe outcome is a winner based on the game specifications in step 104.

If the outcome includes a winning combination, the software applicationmoves to step 106 to determine if the winning combination is eligiblefor a bonus spin. If the combination is not eligible for the bonus spin,the application will add the prize amount to the accumulated winnings ofthe multigame eCard thus far in step 107. If the winning combination iseligible for a bonus spin, in step 108 the application will activate thebonus spin and display the results. In step 109, the application willset the accumulated winnings of the multigame eCard to the amount won bythe bonus spin, the program then moves to step 110 where the applicationdisplays a “ticket complete” message. In step 105, if there is nowinning outcome, the software application determines if there are gameoutcomes left to display. If there are, the program loops back to step103.

If all game outcomes have been displayed, the software applicationproceeds to step 110 and displays a “ticket complete” message. The nextstep 111 is for the player to return the multigame eCard (if there isone or more winning outcomes). Dependent on the game rules, the playermay return the eCard to an authorized retailer, return the ticketdirectly to the main lottery office, or redeem electronically (ifpermitted). Once the eCard has been returned, in step 112 the eCardinformation will be validated and the database will be updated toindicate the multigame eCard has been completed and retired. The finalstep 113 is for the player to receive the accumulated winning amountfrom the multigame. This could be in various forms such as but notlimited to cash, check, or electronic transfer based on the game rules.The process completes in step 114.

FIG. 4(a) provides a game specification breakdown 130 for a sampleePullTab lottery game. There will be a total of 10,800,000 game outcomescreated for the game. The predetermined game outcomes will be dividedinto 50 groups called “pools” containing 216,00 outcomes each. The costper game as defined by game rules is $2.00 per game or outcome. Theprize schedule 131 in FIG. 4(b) shows the individual prize counts foreach base monetary prize tier. The bonus schedule 132 in FIG. 4(c) showsthe individual prize counts for each multiplier level. From the totalnumber of games and the tier level prize counts, the odds of eachspecific prize tier can be calculated. The eCard Distribution 133 inFIG. 4(d) shows the number and value of the eCards initialized. Based onthe cost per ePullTab game and the Card Value, the total number ofePullTab games stored on the individual eCard can be calculated.

As seen in FIGS. 4(a)-(d), there are 13 possible winning outcomes. The13 outcomes are “tokenized” (encoded) into a single 8-bit numeric value(byte). With just 13 of 256 possibilities used, there is an opportunityto add further winning possibilities to a game “hand”.

FIG. 5 is a flowchart for the population and randomization of the fiftyprize pool arrays. It should be noted this flowchart, as well as thefollowing flowcharts, are based on the game specification example inFIG. 4 for the numbers used, and that aspect is not intended to belimiting. The function begins at “start” 150. The first step in theprocess is a software call to the Prize Pool Determination function instep 151. A table is loaded into the database's memory which assigns atoken number to each prize level in step 152.

Variables called Pool_ID and Array_Pointer are respectively initializedto zero in steps 153, 154. The subfunction Prize Pool Population iscalled next in step 155. Once the prize pool array is populated with theappropriate prize tokens, another subfunction is called to perform aDurstenfeld Shuffle in step 156 to randomize the prize pool array. Itshould be noted while the Durstenfeld Shuffle is used in thisembodiment, other embodiments can utilize alternative randomizationapproaches. When the randomization is completed, the prize pool array isstored in step 157 into the main database. The variable Pool_ID isincremented by one in step 158. The variable is then checked to see ifit is equal to fifty in step 159, indicating if there are more prizepool arrays to populate and shuffle. If there are more arrays topopulate, the method begins to populate the next array by returning tostep 155, otherwise the method ends in step 160.

FIG. 6 is a flowchart for the process used to determine which prizepools will contain the prizes, which are less than one per pool asdefined in the game specifications. In this example, the prizedetermination method will determine which prize pool array will containthe token numbers for the $5000*200× multiplier (token #12), $5000*20×multiplier (token #11), $5000*2× multiplier (token #10), $5000*1×multiplier (token #9) and the $600*200× multiplier (token #8) prizes.The function enters at start 200 and creates a temporary array of 50elements and populates the positions with values between 0 to 49,representing the 50 prize pool arrays in step 201. The method nextperforms a Durstenfeld Shuffle in step 202 to randomize the values ofthe array. As mentioned earlier, the Durstenfeld Shuffle is only onetype of randomization approach and other approaches can be utilized inother embodiments. When the shuffle is completed, the first arrayelement is retrieved in step 203 and will be used to indicate whichprize pool will contain the token number for the prize of $5000*200×multiplier. The next 33 array elements are retrieved in step 204 andwill be used to indicate which prize pools will contain the token numberfor the prize of $600*200× multiplier. The next 2 elements are retrievedin step 205, followed by the next 6 elements in step 206 and finally thenext 6 elements are retrieved in step 207. These 14 elements will beused to indicate which prize pools will contain the token numbers for$5000*20× multiplier, $5000*2× multiplier and the $5000*1× multiplier,respectively. The function returns to the calling program in step 208.

FIGS. 7(a) and 7(b) are flowcharts for the process which populates eachof the 50 prize pool arrays with the tokens for the prizes available towin. The process starts at step 250 in FIG. 7(a). The process thenbegins by creating pool_array with 216,000 elements all assigned to zeroin step 251, which is the token number for a non-winning game outcome.The process then checks if the Pool_ID variable (which is passed fromthe calling array) indicates this is a pool array which receives thetoken for a $5000*200× multiplier game in step 252. If yes, the methodreplaces the element in the pool array at the location of the arraypointer with token #12 in step 253 before incrementing the array pointerin step 254. Next, the process checks to see if this pool_array willcontain the token for a $600*200× winner in step 255. If yes, the methodupdates the current element to #8 in step 256 before incrementing thearray pointer in step 257. In step 258 the process checks to see if thetoken for the $5000*20× prize should be included. If yes, the methodupdates the array value to #11 in step 259 before incrementing the arraypointer in step 260. The process then checks if the $5000*2× tokenshould be included in this pool array (Step 261). If yes, the processupdates the array location with #10 in step 262 and increments thepointer in step 263. The process performs the last check for the prizetoken for the $5000*1× prize in step 264. If the token should beincluded, the array element is updated to #9 in step 265 and the arraypointer is updated in step 266. Continuing in FIG. 7(b) there are two$600*20× winners per prize pool, the process populates the next indexwith token #7 in step 267. Not shown is the process of incrementing thearray_pointer by the number of indexes updated, in this case the pointeris incremented by two. The next 8 indexes are populated with token #6for the $600*2× winner in Step 268 and the array_pointer is incrementedby 8 (also not shown). The next 55 indexes are populated with token #5for the $600*1× winners in step 269 and the array_pointer is incrementedby 55 (also not shown). The process populates the next 421 indexes withtoken #4 in step 270, increments the array_pointer (not shown) beforepopulating the following 3375 indexes with token #3 in step 271. Theprocess continues the population of the specified number of indexes insteps 272, and 273 of the array and incrementing of the array pointer(not shown) for each prize level. The remaining indexes in thepool_array have already been initialized to zero, which is the tokennumber for non-winning game outcomes tickets. The method returns to thecalling method in step 274.

FIGS. 8(a) and 8(b) show the process flowchart for the generation of theeCard batches. The process starts at step 400 in FIG. 8(a). VariablesPoolCnt and IndexPtr are initialized in steps 401 and 402, respectively.The pool_array(PoolCount) is copied to a temporary working variablecalled CardArray( ) in step 403. A Durstenfeld shuffle is performed onCardArray( ) in step 404, where the Durstenfeld Shuffle is a nonlimitingexample of a randomization approach. In step 407, one hundred elementsare copied from CardArray( ) to PrizeOutcomes( ). The number one hundredrepresents the number of games associated with the three hundred eCardsper prize pool with a value of two hundred. A thirteen element arraycalled PrizeTally( ) is created in step 405 to contain the count of eachprize tier associated with this eCard batch. In step 408, the processcycles through PrizeOutcomes( ) one element at a time incrementing theassociated PrizeTally( ) element corresponding to the token # stored inthe PrizeOutcomes( ) element. When all counts are tallied, the processcontinues at step 409 to call the function to initialize the eCard. Theprogram continues at step 410 to determine if three hundred eCards havebeen initialized with one hundred outcomes. If no, the programincrements the CardCnt variable by one (not shown) before returning tostep 407; otherwise the program resets the CardCnt variable to zero instep 411. If three hundred eCards have been initialized, the processcopies the next fifty elements in CardArray( ) to the PrizeOutcomes( )array in step 412. Fifty represents the number of games associated withthe eCards with a value of one hundred. The individual outcomes aretallied and stored in PrizeTally( ) array in step 413 before the eCardinitialization process is performed in step 414. The process checks if atotal of four hundred eCards have been initialized with fifty outcomesin step 415. If not, the process increments CardCnt (not shown) beforelooping to step 412.

Otherwise, the process continues to step 416 in FIG. 8(b) to reset theCardCnt variable to zero. The process copies the next twenty elements inCardArray( ) to the PrizeOutcomes( ) array in step 417. Twentyrepresents the number of games associated with the eCards with a valueof forty. The individual outcomes are tallied and stored in PrizeTally() array in step 418 before the eCard initialization process is performedin step 419. The process checks if a total of four thousand eCards havebeen initialized with twenty outcomes in step 420. If not, the processincrements CardCnt (not shown) before looping to step 417. Otherwise theprocess continues to step 421 to reset the CardCnt variable to zero. Theprocess copies the next ten elements in CardArray( ) to thePrizeOutcomes( ) array in step 422. Ten represents the number of gamesassociated with the eCards with a value of twenty. The individualoutcomes are tallied and stored in PrizeTally( ) array in step 423before the eCard initialization process is performed in step 424. Theprocess checks if a total of seven thousand eCards have been initializedwith ten outcomes in step 425. If not, the process increments CardCnt(not shown) before looping to step 422. Otherwise the process continuesto step 426 to reset the CardCnt variable to zero. The process copiesthe next five elements in CardArray( ) to the PrizeOutcomes( ) array instep 427. Five represents the number of games associated with the eCardswith a value of ten. The individual outcomes are tallied and stored inPrizeTally( ) array in step 428 before the eCard initialization processis performed in step 429. The process checks if a total of threethousand two hundred eCards have been initialized with ten outcomes instep 430. If not, the process increments CardCnt (not shown) beforelooping to step 427. In step 431, the process increments the variablePoolCnt before checking to see if it is equal to fifty in step 432. Ifall fifty prize pools have been processed (batched) the process ends instep 433, otherwise the program loops to step 403 in FIG. 8(a) to repeatthe “batching” process for the next prize pool.

FIG. 9 shows a process flowchart for the Durstenfeld Shuffle functionused to randomize the various data arrays. The process enters thefunction through the “Start” block in step 300. Since numerous sequencesof routines utilize this function, the Shuffle_Count variable must beset to equal the Array_Size in step 301 and the Array_Pointer variableis set to Array_Size−1 in step 302. Once a 32-Bit true random number isgenerated in step 303, a modulus function is performed in step 304 toensure the random number generated is within the range of 0 to theArray_Pointer. The result of the modulus function is set to theSwap_Pointer in step 305 and the values in the array stored atArray_Pointer and Swap_Pointer are transposed in step 306. The variableshuffle_count is decremented by one in step 307 and checked to see if itis equal to zero in step 308. If shuffle_count is not equal to zero,there are more elements to shuffle so Array_Pointer is decremented byone in step 309 and the process repeats from the selection of the 32-bitnumber in step 303. Once shuffle_count equals zero, the shuffle of thearray has been completed and the function can return to the callingroutine in step 310.

There are many ways to shuffle data including but not limited to theFisher and Yates' method, Durstenfeld shuffle, “inside-out” algorithm,and Sattolo's algorithm. However, the Durstenfeld shuffle is one of themost effective algorithms for shuffling. One of the advantages ofperforming a Durstenfeld shuffle is the speed at which it performs. Itrequires a decrementing pointer that reduces the size of the swap field.A random number generator is used to select a pair of swap pointers toperform a single swap. As the swap field is reduced, a modulus isapplied to the random numbers. In order to achieve optimal shuffleresults, a true random number (hardware) should be used and truncationbias must be accounted for when applying a modulus function to therandom number outcome.

FIG. 10 is a flowchart for the process of generating a true randomnumber between the values of 0 and “N”. This flowchart produces therandom numbers, which can later be “shuffled” into further random orderutilizing the Durstenfeld Shuffle method. The term “true” indicates thatsome physical source of noise or random behavior is being measured andan unsigned 32-bit digital number is produced. Some examples of physicalrandom sources are nuclear decay of a radioactive material, white noisevoltages produced by a resistor at a specific temperature, randomlyphased oscillators being sampled, or semiconductor “shot” noise. The keyattribute of the various “noise” sources is that they arenon-deterministic in terms of behavior and can only be described on astatistical basis. Usually the physical noise source is “whitened” usingsoftware to decorrelate sample values. By example, if left as anunsigned 32-bit integer, the random values would vary from 0 to4,294,967,296.

When targeting specific probabilities, a modulus function is used to setthe upper limit on the random outcome, by example 1 in 100. A modulus of100 applied to the 32-bit raw random number value will produce a randomvalue of 0-99. The modulus function is based on an arithmetic decisionfunction generally expressed as: N/D, remainder R. By example, if N is10 and D is 8, then R=2. For random number generation, the modulusfunction introduces “truncation bias” which will affect the statisticaloutcome. The effect of truncation bias must be compensated for whenproducing a random integer value between 0 and “N”.

The process starts in step 330. In step 331 the function of generating a32-bit unsigned random number between a value of 0 to “N” starts, whereN is an input variable defining the upper limit of the random numberreturn. Step 332 determines an “ANDing” logical bit mask to be appliedto the modulus “N” to correct for truncation bias, to be describedfurther in FIG. 12. Step 333 traps an error whereby, the modulus is 0and returns to the calling function at step 334.

Step 335 starts the process of requesting an unsigned 32-bit hardwaregenerated random number. Step 336 executes a suitable function to accessthe true random number generator. Step 337 applies the truncationcorrection bit mask. Step 338 determines if the random number exceedsthe modulus limit defined by the bit mask.

If the random number is within the limits of the bit mask, the value isreturned at step 341. If the random number exceeds the bit mask limit,the loop_count is incremented in step 339 and the loop_count limit ischecked in step 340. If loop_count is exceeded, then an error isreturned in step 342, otherwise a new random number is selected byreturning to step 336.

FIG. 11 provides details on creating a modulus bit mask in flowchartform. The modulus value is in a 32-bit unsigned format, which can bebroken into four 8-bit groups (bytes). Each byte of the modulus ischecked for a non-zero value in steps 351, 354, 357, 360. If found, aTable_Offset variable is set accordingly in steps 352, 355, 358, 361 anda bit mask will be resolved in respective steps 353, 356, 359, 362. Thefunction exits in step 364. If all four groups are set to 0, then themodulus is set to 0, which is an illegal value. If a 0 modulus isdetected, an error flag is set (zero_flag) in step 363 and the functionexits 364.

FIG. 12 is a flowchart depicting the routine for initializing theeCards. The process enters at step 450 and initializes an array calledDataCode( ) in step 451. The process generates an 8 byte Security IDCode and stores in the DataCode( ) array in step 452. In step 453, theprocess stores the 4 byte game series code in DataCode before loadingthe 1 byte value indicating the number of outcomes stored on the eCardin step 454. The process then encodes and copies the thirteen elementPrizeTally( ) array into DataCode( ) in step 455. In step 456, theprocess calculates and stores the total winning amount associated withthe batch of game outcomes into the DataCode( ). The process calculatesand stores a CRC-32 checksum into the DataCode( ) array in step 457. ForeCard verification purposes, the DataCode( ) array is stored in theMaster Database in step 458 before being loaded onto the eCard in step459. If the process is successful, the status bit on the eCard and inthe Master database is set in step 460. The process exits and returns tothe calling program in step 461.

The system and method for a multigame eCard as described herein utilizesa security method and system defined by embodiments of the inventionfound in U.S. Pat. No. 8,870,084 ('084 patent), which is hereinincorporated by reference in its entirety. The following is a summary ofthe '084 invention operating as a security system and method for amultigame eCard and system.

FIGS. 13 and 14 illustrate a security key generation and validationsystem according to the embodiment of the present invention. Thesecurity generation process includes the following: An index numbergenerator 500 is connected to a symmetrical encryption/decryption unit502. Private key #1 501 selects the index number security ordered pairsgenerated by the symmetrical encryption/decryption unit 502. Also,acting as control elements to the encryption/decryption unit are theword size control 508 and mode 507 inputs. The word size 508 controlinput defines the number of bits used as a digital word for both theinput and output ports of the symmetrical encryption/decryption unit502. The mode input 507 identifies the mode of operation as encryption.The input of the key security module 504 is connected to the output ofthe symmetrical encryption/decryption unit 502. Private key #2 503controls the generation of a security code that is concatenated with theinput of the key security module 504 and placed into the extended keyoutput buffer 506. The output of extended key output 506 is an 8-byteextended key 505.

The security validation process starts with the contents of extended keyoutput buffer 506 (e.g. the 8-byte extended key 515) being placed intothe extended key input buffer 516. This is done by any means, such as awired or wireless communications path, disk file, or human keyboardinput, as nonlimiting examples. The contents of the extended key inputbuffer 516 act as an input to the extended key code validator 530. Theextended key code validator 530 produces a validity status 529,indicating if the key is valid. The validity status of the extended keycode validator 530 will indicate if the content of the extended keyinput buffer 516 were produced by a key generator whereby private key #2517 matches that of private key #2 503. If the validity status isaffirmative, a process sequencer (not shown) will proceed to convert theextended key to a number index value by way of the symmetricalencryption/decryption unit 526. The symmetrical encryption/decryptionunit has two control inputs, word size 528 and mode 527. Word size 528defines the number of bits that are operated upon. Mode 527 is a singlebit control defining encryption or decryption mode. The operation andfunctionality of the symmetrical encryption/decryption unit 526 isidentical to that of 502 except that the mode is set to decryption. Ifthe validity status is negative, indicating the extended key was notgenerated by an authorized key generator as defined by this invention ornot utilizing the same private key #2 517, 503, the process sequencer(not shown) will abort any further processing and take appropriateactions to indicate the invalidity of the processed contents of theextended key input buffer 516.

The output of the symmetrical encryption/decryption unit 526 isconnected to both the input of a number range verifier 524 and a bitvector management process 521. The number range verification 524generates a range status 523, which indicates whether the number iswithin an upper 522 and lower bound 525. The process sequencer mayoptionally use the index value output from the symmetricalencryption/decryption unit 526 to verify if a bit is set in a bit vector(not shown) located within the bit vector management process. If theprocess sequencer determines the bit is set, it would indicate that thekey code in the extended key input buffer had been processed at aprevious time and should abort any further processing of the extendedkey as well to take appropriate actions to invalidate the extended keyinput. The number range verifier 524 will determine if the input of thenumber range verifier 524 is greater than or equal to the “B” input 525to the number range verifier 524 and less than or equal to the “C” input522 of the number range verifier 524. The range status 523 of the numberrange verifier 524 will provide a binary status if the input is withinthe range of values “B” and “C”. The bit vector management process 521will set a bit within a bit vector (not shown) as specified by the indexvalue output from the symmetrical encryption/decryption unit 526.Setting the bit within the bit vector indicates that the extended keywas valid and has been processed.

Symmetric, secret-key, and block encryption/decryption methods(symmetric-key) are defined as a class of algorithms for cryptographythat use identical cryptographic keys for both encryption of plaintextand decryption of ciphertext. In practice, the keys represent a sharedsecret. Other terms for symmetric-key encryption are secret-key,single-key, shared-key, one-key, and private-key encryption.

Symmetric-key cryptography transforms (scrambles) a message intosomething resembling random noise. The key determines the precisetransformation. Mathematically, a cryptographic algorithm is a functionthat maps a message onto a ciphertext (an encrypted message). By usingkeys, it is possible to encrypt many different messages using oneparticular cryptographic algorithm with a different outcome for eachkey.

Some cryptographic algorithms that operate on fixed word lengths arereferred to as block ciphers. Block (word) sizes of 32, 64, and 256 bitsare commonly used. Some nonlimiting examples of popular andwell-respected symmetric encryption/decryption algorithms are Twofish,Serpent, AES (Rijndael), Blowfish, CAST5, RC4, DES, Triple-DES, andIDEA.

FIG. 15 is a flowchart for the routine which encodes the prize tokentally counts stored in the PrizeTally( ) arrays. The routine enters at550. The variable TallyCnt is initialized to zero in step 551. In step552 a random number between 0-255 is generated. The bit mask modulusfunction is called in step 553 to eliminate truncation bias. The randomnumber is assigned to the variable tableptr in step 554 as the indexinto a 256 byte table stored in memory. The value stored in the table attableptr is retrieved and exclusive ORed with the value at locationGameCnt in the PrizeTally( ) array in step 555. The encoded value isstored in the DataCode array in step 556. The process of “exclusiveORing” obscures the value of the tally count of the tokenizedpredetermined game outcomes with random data. This is equivalent toadding an opaque “scratch off” layer to a conventional scratch off gameticket. To retrieve the original token value, the “obscured” taken valueis exclusive ORed again with the same random value. The variableTallyCnt is incremented in step 557 and compared to thirteen in step559. Thirteen is the number of prize tiers (tally counts) associatedwith the ePullTab game. If the variable equals thirteen, indicating alltally counts have been encoded, the routine ends and returns to thecalling program in step 561. If the variable does not equal 13, tableptris incremented in step 560. The variable is then AND'd with 255,producing a value between 0-255, in step 558, before looping back tostep 555.

The prize tally count encoding process described above and in FIG. 15provides a randomizing process to obscure the actual token values. Itshould be noted that at step 552 a software based random number is used.A nonlimiting example is the linear congruential random numbergenerator: 13*X+1. This simple random number generator when restrictedto 8 bit unsigned numbers will appear to produce random number valuesbetween 0 and 255. No two numbers will be repeated until the cyclestarts over. When the game parameters are downloaded from the hostduring the eCard “pairing” process a “seed” 8 bit value is identified asa starting value for the software based random number generator.

FIG. 16 is a top-level flowchart of the application for a smart device.The program begins at step 600 and checks to see if there are gameoutcomes left from a previously scanned ticket in step 601. If there isa game in progress, the program skips forward to step 607. Otherwise,the program waits for the player to begin the “pairing” process betweenthe eCard and the smart device 602. The program retrieves and decodesthe information stored in the electronic memory on the eCard in step603.

In step 604, the software application determines, based on the gameseries code, if this is the first time this game variation has beenaccessed on this device. If yes, the software application branches offto the routine to download game parameters from the applicable onlineresource in step 605. Once game parameters have been downloaded, theapplication in step 606 creates, populates, and then shuffles aGameOutcome Array based on the tally counts stored on the eCard.

In step 607, the software application restores (if a previous game wasin progress) or initializes (if a new eCard) various game variables. Thesoftware application then retrieves the next (or first) game outcome tobe displayed in step 608. Based on the game outcome and game informationdownloaded, the software application in step 609 calculates theappropriate game screen to display to achieve the proper game outcome.The software application then displays the game screen in step 610, withall tabs “covered”. The software application waits for the player toselect a tab to display (not shown) before revealing the selected tab instep 611. If all tabs have not been displayed in step 612, the softwareapplication loops back to step 611. Otherwise, the software applicationcontinues to step 613 where the application determines if the gameoutcome warrants a bonus spin. If a bonus spin is available, theapplication performs the bonus spin in step 614. As per the game rules,the eCard accumulated winning amount is set to equal the amount won inthe bonus spin in step 616 before proceeding to step 618. If a bonusspin is not available in step 613, the application adds the winningamount for the game, if any, to the accumulated winnings thus far earnedfor the eCard in step 615. The games remaining count is decremented (notshown) and the software application determines if there are anyremaining outcomes to display at step 617. If yes, the program waits forthe player to initiate a new hand (not shown) before looping back tostep 608, otherwise it continues to step 618 and displays a game overmessage. The software application then connects via the internet to themaster database to change the status of the eCard to complete in step619. The program ends at step 620.

FIG. 17 is a pictorial representation of an implementation of anonlimiting game. The display on the smart device 650 shows the game'spayout table and associated winning symbol combinations. It illustratesto the player the three symbols 651 that need to be aligned (in apattern defined in the game rules) to win the indicated amount 652.According to the game rules all games winning an amount of $600 or $5000will also be awarded a bonus spin.

FIG. 18 is a pictorial representation of an implementation of anonlimiting game in progress. The display on the smart device 650 showsthe game screen. On the game screen is the play board 660 which containsthe 5 individual “tabs” 660, 661, 662. When the game begins, all 5 tabsare “covered” and are “opened” as the player taps the individual tabs.Also located on the play board is the “auto play” virtual button 654.This can be used by the player to quickly reveal all the remaining tabsin the game. Once all 5 tabs are revealed, the player selects the “playnext game” virtual button 653 to display the next hand, if available. Ifthe player wishes to exit the software application and continue at alater time, they can select the “exit” virtual button 655.

FIG. 19 is a pictorial representation of an implementation of anonlimiting game's bonus spin in progress. The display on the smartdevice 650 shows the game screen with the bonus spin overlay 670. Theoverlay emulates the spinning motion of the potential bonus multiplier.

FIG. 20 is a pictorial representation of an implementation of anonlimiting game's bonus spin result. The display on the smart device650 shows the game screen with the results of the bonus spin 680. Inthis example the winning amount would be $10000 indicated by the 3triple bars (5000 winner) with the line multiplied by the 2× multiplier.

FIGS. 21(a) and 21(b) represent an example of the rules associated witha predetermined multigame ticket game 700. The rules indicate a game IDnumber along with the cost to purchase a multigame eCard from anauthorized retailer. The play symbols which may appear in the “GameBoard” area are defined. Also defined are the available prizes that canbe won on a multigame eCard and the total number of game outcomes thatwill be produced for this game.

How and which prize a player wins is defined next in the rules. There isa table included in the rules that shows in more detail the prizesavailable to win.

FIG. 22 depicts an example of a server farm associated with the mainlottery office 52. The server farm is illustrated simply for exemplarypurposes and is not intended to be limiting. The server farm includesany number of web devices 1 through N, illustrated here as web device805A and web device 805B. The web devices are connected via the internet806 to a hardware load-balancing server 801 through a router 800,firewall 808, and TCP/IP 807. The hardware load-balancing server 801 anda raid disk subsystem 804 are connected to any number of webservercomputers, illustrated here as computers 802A-D, via a LAN switch 803.

FIG. 23 depicts an example of a specification computer system associatedwith the game file specification 59. The specification computer systemis illustrated simply for exemplary purposes and is not intended to belimiting. A computing system 857 is connected to the Internet 854through a firewall 855 and is also connected to a printer 850. Thecomputing system 857 includes a hardware based true random numbergenerator 856, as well as a multigame ticket specification file 851, aspecification image init file (master database) 852, and customapplication software 853.

FIG. 24 depicts an example of an eCard initialization computer subsystemassociated with the eCard manufacturing facility 50. The initializationcomputer subsystem is illustrated simply for exemplary purposes and isnot intended to be limiting. A computing system 901 is connected to theInternet 905 through a firewall 904. The computing system 901 includesan initialization utility 903 for receipt of a specification image initfile for multigame eCard initialization 902. The eCard initialization isillustrated as a hardwired eCard reader/writer for exemplary purposesonly and is not intended to be limited. eCard initialization may beperformed using other communication technology either wired or wirelesssuch as serial, USB, Bluetooth, NFC, etc.

It is understood that the above-described embodiments are onlyillustrative of the application of the principles of the presentinvention. The present invention may be embodied in other specific formswithout departing from its spirit or essential characteristics. Allchanges that come within the meaning and range of equivalency of theclaims are to be embraced within their scope. Thus, while the presentinvention has been fully described above with particularity and detailin connection with what is presently deemed to be the most practical andpreferred embodiment of the invention, it will be apparent to those ofordinary skill in the art that numerous modifications may be madewithout departing from the principles and concepts of the invention asset forth in the claims.

What is claimed is:
 1. A method for implementing a multigame, the methodcomprising: randomly generating a plurality of game outcomes for themultigame; grouping the plurality of game outcomes into a plurality ofbatches according to a game specification; assigning a batch number toeach of the plurality of batches; defining a number of game outcomes ineach batch as a tally count; encoding each batch number and each tallycount with a security code; electronically storing each encoded batchnumber and each encoded tally count in a respective game card, each gamecard configured to wirelessly communicate the encoded batch number andencoded tally count to a user computing device; and providing a gameapplication for downloading by the user computing device, theapplication being configured to provide a gaming display on the usercomputing device to allow for playing the multigame based on the encodedbatch number.
 2. The method of claim 1, wherein the application isfurther configured to provide the gaming display on the user computingdevice to allow for playing the multigame based on the encoded tallycount.
 3. The method of claim 1, further comprising encoding each batchnumber with an error detecting code.
 4. The method of claim 3, whereinthe error detecting code comprises a 32-bit cyclic redundancy check. 5.The method of claim 1, wherein the security code is based on a privatesecurity key generation and validation process.
 6. The method of claim1, wherein the security code comprises a private security key that isgenerated and validated using a symmetric-key process.
 7. The method ofclaim 1, wherein randomly generating the plurality of game outcomescomprises shuffling the plurality of game outcomes.
 8. The method ofclaim 7, wherein the shuffling comprises a Durstenfeld shuffle.
 9. Themethod of claim 7, wherein the shuffling comprises applying a modulusbit mask to the plurality of game outcomes.
 10. The method of claim 1,further comprising tokenizing each of the plurality of game batches intoa finite word length digital representation.
 11. The method of claim 10,further comprising obscuring the tokenized game batches by exclusiveORing with a random number, each random number having the same finiteword length as each corresponding game batch token.
 12. An electronicgame card for playing a multigame, comprising: an electronic memoryconfigured to: store an encoded batch number corresponding to one of aplurality of batches of randomly generated game outcomes for themultigame according to a game specification; and store an encoded tallycount defining a number of game outcomes in the respective batch; and adevice for wireless communication configured to wirelessly communicatethe encoded batch number and encoded tally count to a user computingdevice having a downloaded game application that provides a gamingdisplay to allow for playing the multigame based on the encoded batchnumber and encoded tally count.
 13. The electronic game card of claim12, wherein the device for wireless communication comprises one of atransmitter and transceiver.
 14. The electronic game card of claim 12,wherein the wireless communication comprises one of near fieldcommunication (NFC) and Bluetooth communication.
 15. The electronic gamecard of claim 12, wherein the electronic memory does not store the gameapplication.
 16. The electronic game card of claim 12, wherein theencoded batch number is encoded with a security code and an errordetecting code.
 17. The electronic game card of claim 16, wherein theerror detecting code comprises a 32-bit cyclic redundancy check.
 18. Theelectronic game card of claim 16, wherein the security code is based ona private security key generation and validation process.
 19. Theelectronic game card of claim 16, wherein the security code comprises aprivate security key that is generated and validated using asymmetric-key process.